Software of the Month Club 1996 August

home *** CD-ROM | disk | FTP | other *** search

/ Software of the Month Club 1996 August / Software of the Month Club 1996 August.iso / pc / dos / edu / mapit14c / mapitc.pak / GPS_UTIL.TXT < prev next >

Wrap

Text File | 1994-04-15 | 20.5 KB | 438 lines

MAPIT GPS Utilities Package Version 1.0 Copyright 1994 John B. Allison Allison Software 166 Shady Lane Apollo, PA 15613 412-727-2198 CIS: 72600,1200 Internet: 72600.1200@compuserve.com Allison Software's MAPIT GPS Utilities Package is a set of IBM-compatible PC programs designed to capture NMEA 0183 data from a Global Positioning System receiver saving it to computer disk for later transformation into mapping coordinate data for display and use by MAPIT. The Global Positioning System (GPS) consists of 24 satellites maintained by the US Department of Defense. Signals transmitted from these satellites are encoded with precise location and timing information which enable users with GPS receivers to determine their location anywhere in the world with 100 meter accuracy. The MAPIT GPS Utilities allow one to capture real-time positioning data from the output of a GPS receiver through a serial COM port of a computer, save it to a disk file, and later convert that data from its original NMEA 0183 sentence format to ASCII lat/long coordinates. The program GPSTONME saves the GPS data to disk while NMETOMP1 processes the raw data converting it to .MP1 format. A third program, MP1TOMP3, converts the ASCII .MP1 data to MAPIT's binary .MP3 format, completing the sequence. GPSTONME: GPSTONME is part of the MAPIT GPS Utility Package designed to capture data from the output of a GPS (Global Positioning System) receiver and save it to a computer file for later processing and conversion to mapping data. This program expects GPS output in the form of NMEA 0183 Version 2 sentences supplied at 4800 baud at serial COM port 1 - 4 of an IBM-compatible computer. (See Appendix I for port pin configuration.) Once operating, GPSTONME notifies the user when the data signal is acquired, dropped, or missing, saves incoming data to an ASCII file, periodically updates the file system's FAT to reduce data loss due to computer battery failure, and optionally resets the computer's system clock to agree with the time supplied by the GPS. GPSTONME is run from the DOS command line and expects zero or more of the following options: gpstonme [data_file] [command_line_options] data_file The name of an output file in which the raw GPS NMEA 0183 data sentence are to be stored. This ASCII file is defaulted with the extension ".NME" if none is specified. If no data file name is specified, GPSTONME stores the data in a file whose name is generated as part of a series beginning with the year, month, and day of the month of today's date to which is appended the numbers 01, 02, ... 99 to make the name unique. Using self- generated names, the files created on February 28, 1994 would be named 94022801.NME, 94022802.NME, etc. If you want to direct output to the screen, use the special DOS name "CON" which indicates the console and add the command line argument /overwrite to allow output to an already-existing "file". /noclockset By default, GPSTONME updates the computer's system clock to reflect the minutes and seconds as they're delivered real-time from the GPS unit. The hour is not changed in order to protect the local time offset from the Universal Time delivered by the GPS except when the corrected minutes advance or retreat over the hour mark. Even that exception is excepted at the start of a new day. Time corrections are not applied near midnight to avoid the necessity of changing the computer's calendar day and possibly year. Time corrections are applied only when the computer's minutes and seconds are within 10 minutes of the GPS's UT. A message tells the user the difference between these two times and whether the computer's clock has been reset. The user must reset the computer manually with the TIME command to the approximate time if the time difference is too great for automatic update. The option /noclockset overrides the automatic resetting of the computer's clock. /nocommit By default, GPSTONME updates the FAT (File Access Table) of the output file every minute or two as it writes the file to disk. GPSTONME does this because, in event of a power failure or system crash, a data file whose FAT is not updated will not be "saved" although data may have been written to the disk all day long. During real-time data capture, one gets a warm fuzzy feeling knowing that all except the last minute or two of his data is safe in the unlikely event lightening does strike. Data commits also happen when data stops appearing at the COM port and the program issues an informational warning message and when the user types "c" at the keyboard. If you don't want this automatic update of the FAT to occur, enter /nocommit as a command line argument. /overwrite GPSTONME normally gives an error message and doesn't permit the overwriting and destruction of an existing data file by a new one. The /overwrite option allows a file name to be reused. The old file is first truncated. Its data is all destroyed. Use with care. /port=n GPSTONME expects the GPS to be connected to the computer's COM1 serial port. The /port option allows any one of the four ports, 1 through 4, to be selected at program run time. Note that GPSTONME automatically configures the selected port to the correct baud rate, parity, and stop bits. /? This option displays a brief explanation of all command line options on the screen. The foregoing command line options can be truncated to the point of ambiguity without error. (e.g. /p=3 is acceptable as is /port=3.) Possible matches are listed in case of ambiguous input. You can use this fact to force the program to remind you of all possible command line options by entering just a "/". GPSTONME does not respond to keyboard input except for selected commands: c - commit. Force update of the output file's FAT unless the /nocommit is in effect. v - version. Displays version number, copyright notice, and author's address. <Esc> y - exit. Terminate processing. Please note: The serial COM ports are unbuffered and are open to data overrun errors unless special buffered drivers are used. GPSTONME uses standard BIOS calls and may therefore drop characters upon occasion. This means that GPSTONME must be run as a single task and cannot be multi-tasked as a Window's background process. From a practical perspective, there is enough redundant and unused data to make the occasional loss of a few characters inconsequential. The next down-stream program, NMETOMP1, is designed with extensive error checking to weed out "bad" data fields or sentences. Commits and keyboard checking are done at the end of time-outs when the likelihood of incoming data and therefore data overruns is reduced. NMETOMP1: NMETOMP1 is the part of the MAPIT GPS Utility Package designed to convert and process raw NMEA 0183 Version 2 sentence data saved on disk by the GPS Utility program GPSTONME and save it to an ASCII lat/long .MP1 format file. Beyond straight format conversion, NMETOMP1 provides a great deal of error checking, the coalescing of data partially and multiply defined by a sets of NMEA sentences generated from a single fix, the dropping of duplicate points, simple data smoothing, and the pruning of unneeded points. NMETOMP1 is run from the DOS command line and expects the following options: nmetomp1 input_file [output_file] [command_line_options] input_file The required input data file name. The input file must be an ASCII NMEA sentence file whose extension, unless otherwise specified, defaults to ".NME". output_file An optional name for the ASCII .MP1 formatted output file. If no extension is specified, the default extension ".MP1" is used. If no output_file is specified, the input_file name with the extension ".MP1" is used for output. /average /avg Apply a simple smoothing algorithm to the data. Averaging is accomplished after duplicate points are removed and minimum spacing is determined. /average has no noticeable effect on the display of data by MAPIT unless the /minxx=spacing option is applied with a spacing value greater than the 100 foot resolution of MAPIT's ability to reproduce data. See Precision versus Accuracy below for a related discussion. /decimals=n The required number of places of precision after the decimal point for latitude, longitude, and time input data. Defaults to 2. A value of 0 requires none but allows data after the decimal point. The primary purpose of this option is to allow for the further checking for dropped data to the right of the decimal which are not spelled out in the NMEA specification. Because the exact precision of your data is GPS vendor-dependent, you may want to examine the raw data and adjust this option accordingly. As an example, specifying /decimals=1 will cause the otherwise correctly formatted time field "120156" in vendor X's GLL statement to be logged as an error but is not an overall debilitating error if the time is available from another sentence. Some compromise toward less stringent error checking may be necessary. (This is a fine-tuning option. If it works, don't fool unless the output shows too many bad points.) See /error below. /duplicates Don't drop duplicate points but convert all data. By default, NMETOMP1 doesn't convert duplicate points: points taken within half a time second of the previous point or located within a distance of the last point implied by /decimals above (applied to the location expressed in minutes: e.g. /decimals=2 implies a minimum separation of 0.01 minutes). Duplicate points can be created as the GPS looses signal acquisition, in which case the last fix may be retransmitted a number of times, or when physical movement of the GPS ceases. /error Log parsing error messages in output_file.ERR. Errors are normally due to characters dropped by the unbuffered input. /minfeet=n /minft=n /minmeters=n /minkmeters=n /minmiles=n /minnmiles=n Prune (drop) points to support a precision of n feet, meters, kilometers, miles, or nautical miles. GPS fixes can be downloaded as often as every second or two resulting in a huge number of points which may be too close together to be warranted by a particular application. One of the main strengths of NMETOMP1 is the program's ability to reduce the number of points to meet the user's criteria of data spacing and accuracy. The pruning algorithm consists of two parts: fixes which are within the stated distance n of the last fix are dropped as being obviously unnecessary. Also intermediate points falling within a straight line corridor 2n wide between the last accepted fix (anchor point) and the next necessary one are themselves unnecessary. A dramatic reduction in data is possible by specifying a minimum precision of even 500 feet. (Remember that S/A - see below - reduces the accuracy of any given fix to +/-300 feet with a 95% probability.) /unsupported Log unsupported NMEA sentences in output_file.ERR Unsupported NMEA sentences are those of which NMETOMP1 is not aware. They neither hurt nor are interpreted. (See Appendix II for a list of supported sentences.) /? This option displays a brief explanation of all command line options on the screen. The foregoing command line options can be truncated to the point of ambiguity without error. (e.g. /minkm=3 is acceptable as is /minkmeters=3.) Possible matches are listed in case of ambiguous input. You can use this fact to force the program to remind you of all possible command line options by entering just a "/". Example Input/Output: Two samples of data input and one of data output are listed below. The data input, although conforming to the NMEA 0183 version 2.00 specification, can vary from GPS to GPS because of the variety of sentences available, their ordering, data precision, and dropped elements. The input listed below is from a Magellan GPS Meridian, a less expensive if not popular hand- held GPS. The Meridian supports three different types of NMEA output chosen from deep within its menuing system (Aux Menu, second page, NMEA): 0183A, 0813B, and 0813C. The 0813A uses NMEA sentences from a prior standard no longer recommended for use and is not supported by NMETOMP1. 0813B's output is shown in Sample Input A, and 0813C's output is shown in Sample Input B. Note that in both cases a single fix gives rise to multiple sentences which may contain redundant data. (See Appendix II for a list of required and supported sentences.) In the Meridian examples, 0813C (Sample Input B) gives more data unless you require that the date be included. On the other hand, Sample A's data carries mandatory checksums for data accuracy. Sample Input A: $GPRMB,A,0.02,L,0008,0009,4027.05,N,07935.27,W,003.9,162.,00.0,V*21 $GPRMC,200150,A,4030.81,N,07936.83,W,00.0,000.0,150394,08.,W*4C $GPRMB,A,0.01,L,0008,0009,4027.05,N,07935.27,W,003.9,162.,00.0,V*22 $GPRMC,200156,A,4030.80,N,07936.83,W,00.0,000.0,150394,08.,W*4B $GPRMB,A,0.01,L,0008,0009,4027.05,N,07935.27,W,003.9,162.,00.0,V*22 $GPRMC,200157,A,4030.80,N,07936.83,W,00.0,000.0,150394,08.,W*4A Sample Input B: $GPGLL,4030.899,N,07936.455,W,012611.861,A $GPAPB,A,A,0.3,R,N,V,V,162.7,T,009,166.8,T,85.3,T $GPGGA,012611.86,4030.90,N,07936.46,W,1,07,4.1,,,,,, $GPVTG,81.5,T,89.9,M,2.7,N,5.0,K $GPBWC,012611.86,4027.05,N,07935.27,W,166.8,T,175.2,M,4.0,N,009 $GPGLL,4030.910,N,07936.449,W,012615.921,A $GPAPB,A,A,0.3,R,N,V,V,162.7,T,009,166.9,T,160.9,T $GPGGA,012615.92,4030.91,N,07936.45,W,1,07,5.1,,,,,, $GPVTG,6.0,T,14.4,M,8.2,N,15.2,K $GPBWC,012615.92,4027.05,N,07935.27,W,166.9,T,175.3,M,4.0,N,009 $GPGLL,4030.936,N,07936.449,W,012621.369,A $GPAPB,A,A,0.3,R,N,V,V,162.7,T,009,167.0,T,173.6,T $GPGGA,012621.37,4030.94,N,07936.45,W,1,07,3.9,,,,,, $GPVTG,353.4,T,1.8,M,22.7,N,42.1,K $GPBWC,012621.37,4027.05,N,07935.27,W,167.0,T,175.3,M,4.0,N,009 Note: GPAPB Autopilot Sentence "B" - unsupported . GPBWC Bearing & Distance to Waypoint - unsupported. Sample Output: 1 2 3 4 5 6 7 8 9 40.514983 -79.607583 0 012611.861UT 000000 81.5 5.0km/hr 4.1 7 40.515167 -79.607483 0 012615.921UT 000000 6.0 15.2km/hr 5.1 7 40.515600 -79.607483 0 012621.369UT 000000 353.4 42.1km/hr 3.9 7 1 - Latitude in decimal degrees. Negative implies south. 2 - Longitude in decimal degrees. Negative implies west. 3 - Altitude in meters above sea level. 4 - Universal Time (GMT) HHMMSS.SSS 5 - Date at the Prime Meridian. DDMMYY 6 - True course made good. 7 - Speed over ground in kilometers per hour. 8 - Horizontal dilution of precision. 9 - Number of satellites in use (versus in view). 0 - 12. The format of this output, known as .MP1 by Allison Software, is not precisely defined. The program MP1TOMP3 converts the first two columns, the latitude and longitude, to .MP3 format and treats all following text as comments. Whether there are adjustments in the following columns as GPS data conversion evolves remains to be seen. The data is defined in terms of the order of white space-separated characters groups and not by absolute column position. Example Data Collection/Reduction Session: The following DOS commands illustrate the collection and use of GPS data using Allison Software's GPS Utilities. Collect GPS output in an ASCII file named APOLOOP.NME. This scenario presupposes a GPS receiver properly connected to the COM1 port of portable computer collecting meaningful data as you drive down a highway or sail across a lake. Non-meaningful stationary data will work for debugging purposes. C:> gpstonme apoloop Esc Y ; exit program Convert the raw data found in APOLOOP.NME to .mp1 format in the file APOLOOP.MP1. The informational message at the program's conclusion tells you that 785 fixes are output out of a possible 785 (All unique data was transferred) and that there are 76 errors found in the 4,473 NMEA source lines. C:> nmetomp1 apoloop 785 fixes output out of 785. 76 errors in 4473 lines. Create a second .mp1 file with a minimum separation of 500 feet between points. Notice the use of a second file name to, in effect, rename the output to a name different from the input. There are only 92 out of 785 fixes transfered because of the effect of the /minft=500 pruning. C:> nmetomp1 apoloop apoloop2 /minft=500 92 fixes output out of 785. 76 errors in 4473 lines. Convert both these .mp1 files to .mp3 format for use display in MAPIT. Place the first on white layer 120, and the second on red layer 124. C:> mp1tomp3 apoloop /layer=120 C:> mp1tomp3 apoloop2 /lay=124 Display them both in MAPIT so that the 500 foot red layer overwrites the white layer. C:> mapit apoloop /extended=apoloop2 As you zoom in, you'll be able to see which points from the original data were pruned. Run NMETOMP1 with the /avg option to show the results of averaging points. Create a third file using the same minimum spacing of 500 feet but with the averaging option. Compare this file with the 500 foot file with no averaging. C:> nmetomp1 apoloop apoloop3 /minft=500 /avg C:> mp1tomp3 apoloop3 /layer=122 C:> mapit apoloop2 /extended=apoloop3 Precision versus Accuracy: The old conundrum of precision versus accuracy raises its confusing head again in the case of MAPIT-displayed GPS data. MAPIT is able to store points within approximately 100 feet of a location. In other words, a point whose location should be at x may be as much as 100 feet from x in any direction. GPS has the inherent capability of locating points within approximately 50 feet of their actual position. In deference to national security, however, the Department of Defense applies a randomizing signal called Selective Availability (SA) to the GPS system which decreases its accuracy to within plus or minus 300 feet 95% of the time. On the other hand, GPS signals, because of their precision, appear to be very accurate. The Meridian's GPGLL latitude/longitude output with 0.001 degree precision incorrectly implies fixes accurate to six feet! Plotting this data on the MAPIT world of 100 foot squares is like trying to view super VGA data on an old CGA display. But one is quickly reminded that the data's apparent 6 foot accuracy is meaningless when the original reading is superimposed on a second taken some time later. The two readings from the same location may be as much as 600 feet apart! It is important to view all GPS data with a 300 foot halo of uncertainty around it. There are, however, methods of obtaining more accurate GPS fixes. In what might appear to be an internal turf war, the US Coast Guard is establishing a series of transmitter sites along the coast broadcasting correction signals which, when applied to differential GPS receivers, more than compensate for the DOD induced SA, a great boon to boat owners! Similarly, surveying GPS units use locally generated correction signals transmitted from a known point to achieve truly remarkable accuracy within a limited area.